"고객은 다르다"라는 것이 CRM의 출발점이라고 할 수 있겠지요?

기업에서는 고객의 가치를 판단, 예측하고 싶어하고, 고객은 자신의 가치를 다른 고객과 구별되어 인식되기를 원합니다. 그래서 기업은 고객의 정보를 자산으로 인식하여, 체계적으로 수집, 관리, 활용하고 싶어하고, 수집된 정보를 단순히 분석하는 차원을 넘어서, 미래의 잠재가치에 대해서 여러 통계 기법을 통해서 예측하려고 합니다. 또한 고객은 단지 "고객님" 이렇게 불리는 것 보다는 기업이 자신을 VIP고객으로 인식하는지, VVIP고객으로 인식하는지 자신의 가치를 제대로 인정받고, 서비스 받기를 원합니다. 이러한 기업의 요구사항과 고객의 기대사항 사이에 CRM이 있고, 그 가운데 고객정보가 있습니다.

CRM 프로젝트를 수행하면서, 고객정보를 통합하는 업무를 수행하는 경우가 많습니다. 이글을 통해서 고객정보를 통합하는 과정에서 관심 있게 챙겨야 할 포인트에 대해서 말씀드리고자 합니다.

1. 고객정보는 Master성 데이터와 Transaction성 데이터로 나눌 수 있습니다.

   "홈페이지에 회원으로 가입을 해서, 주문을 했다"라는 상황에서 발생한 데이터를 분별해 보면, Master성 데이터와 Transaction성 데이터로 나눌 수 있습니다.

     - Master : 회원

     - Transaction : 주문

   Master데이터는 최신의 정보로 관리되고, 회원 아이디와 같은 값으로 찾을 때 중복되어 결과를 되돌려 주지는 않습니다. 그러나 Transaction 데이터는 이력정보인 경우가 많고 (주문 이력), 회원 아이디로 찾아도 주문 횟수만큼의 고객정보를 되돌려 줍니다. 개발된 시스템의 목적에 따라서 고객 정보가 Master 성 데이터로만 저장되지 않고, 주문 데이터처럼 Transaction 성 데이터로 저장된 정보를 통합해야 하는 경우(주문정보 속에서 고객정보를 찾아내는 경우)가 있습니다. 이럴 경우에는 중복되는 고객정보 중에서 어느 데이터를 취해야 할지, 선택할 때의 우선 순위는 단순히 최신 날짜로만 해야 할지를 판단할 필요가 있습니다. 따라서 통합 고객 DB를 구축하려고 할 때, 통합 대상이 되는 고객정보가 Master성 데이터인지, Transaction 성 데이터인지 구분을 하고, 각각의 속성에 맞게 설계를 해야 합니다.

2. 통합 DB보다 내 DB가 더 신뢰가 간다.

  통합 대상인 데이터베이스가 A,B,C 이렇게 3개의 데이터베이스가 있습니다. 이중 A 데이터베이스는 고객정보의 관리가 아주 잘 되어 있고(고객의 실명 정보를 유지하고, 필수 입력값의 정의도 잘 되어 있어서 마케팅 활용도가 높음), 반면에 B,C 데이터베이스는 고객정보가 잘 관리되어 있지 않다고 가정을 합니다. 이럴 경우에 통합된 데이터베이스의 퀄리티가 B,C 데이터베이스 사용자의 기대수준을 만족시킬 수는 있지만, A 데이터베이스의 사용자의 만족을 가져오지 못할 수 있습니다. 오히려 A 데이터베이스 사용자는 B,C 데이터베이스와 통합을 하면서 노이즈가 발생하고, 통합과정에서 A 데이터베이스의 업무 특성에 맞는 항목이 손실되었다고 생각할 수 있고, 통합 데이터베이스의 활용을 주저하고 A 데이터베이스의 사용을 고집하는 상황이 발생할 수 있습니다. 더우기 통합 DB가 A,B,C 데이터베이스를 대체하는 경우라면 A 데이터 베이스의 저항은 더 커질 수 있습니다. 이럴 때에는 A 데이터베이스의 노이즈에 대한 우려와 업무 특성 데이터의 손실에 대한 우려를 정성적, 정량적으로 분석해서 해결하는 것 못지 않게 통합 DB 구축의 목적과 효용 등에 대한 설득작업도 필요하게 됩니다.

3. 데이터의 통합과정은 초기이행과 변경이행이 있다.

  고객데이터의 통합은 특정 싯점까지 저장된 고객정보를 통합하는 "초기 이행"과 초기 이행 이후에 추가/변경된 데이터를 통합하는 "변경 이행"으로 나눠서 생각할 수 있습니다. 각각의 특징은 다음과 같습니다.

    - 초기 이행 : 단일하지만 긴 트랜잭션 / 시스템의